The 3rd Generation Partnership Project (3GPP) is a globally applicable third generation mobile phone system specification that is a result of collaboration between various groups of telecommunications associations, including the European Telecommunications Standards Institute, the Association of Radio Industries and Businesses/Telecommunication Technology Committee (ARIB/TTC), China Communications Standards Association, and the Alliance for Telecommunications Industry Solutions. 3GPP work is ongoing with Universal Terrestrial Radio Access Network (UTRAN) long term evolution (LTE). The 3GPP RAN2 working group has defined a Discontinuous Reception (DRX) mechanism to save battery life and resources of user equipment (UE). The main principle in DRX is that the user equipment (UE) behavior is defined relative to the successful decoding of the Physical Downlink Control Channel (PDCCH) by the UE. When the UE is in DRX, the UE is allowed to stop monitoring the PDCCH. DRX uses one or two pre-defined cycles (long and/or short cycles), at the beginning of which the UE monitors the PDCCH over a certain amount of transmission time intervals (TTIs), according to an “On Duration” Timer. The PDCCH carries downlink (DL) assignments as well as uplink (UL) grants.
Whether the UE is awake (e.g., is monitoring the PDCCH) or asleep after the On Duration period, depends on activity (i.e., possible reception of PDCCH control data during the period). To avoid unnecessary scheduling and to avoid wasting of radio resources, the base station (e.g., eNodeB) should know the state of the UE when transmitting downlink data from the base station to the UE. Thus, a set of clear rules for changing from the active state to DRX and back are defined in 3GPP Technical Specification (TS) 36.321, “Medium Access Control (MAC) Specification.”
In LTE, the characteristics of the DRX scheme for the UL include the following:
1) the UE can be configured with a Short DRX cycle, which is a full fraction of the (Long) DRX cycle (i.e., Long DRX=x*Short DRX).
2) On Duration Timer in the beginning of each cycle defines how long the UE should monitor PDCCH. There are two types of cycles, long and short.
3) if only UL traffic exists, the UE should monitor PDCCH if                a) On Duration Timer is running;        b) DRX Inactivity timer is running;        c) a scheduling request (SR) is pending. SR is considered to be pending from the triggering of a SR until the receiving of any grant;        d) a grant for retransmission can arrive. Assuming synchronous hybrid automatic repeat request (HARQ) on the UL, retransmission can occur after 8 ms of the previous transmission;        
4) if PDCCH indicates UL transmission for new data, the UE should start or restart a DRX Inactivity Timer. When the inactivity timer expires, the UE should start to use the short cycle if it is configured. Use of the short cycle is stopped when the Short DRX Cycle Timer is expired. A typical DRX pattern with only long cycles is illustrated in FIG. 1. As shown in FIG. 1, the UE first sends a scheduling request (SR) to a base station (BS) and then monitors the PDCCH until the initial grant is received as a response to the SR. Using the received grant, the UE sends a regular buffer status report (BSR) of existing data in the buffer. Finally, after receiving a new grant, the UE can send actual data. The BS and the UE have similar inactivity timers and knowledge of the beginning times of the long cycles and, thus, the state of the UE does not have to be signaled explicitly between the BS and UE.
In order to ensure that the UE is listening on the PDCCH when an UL grant, as a response to a reported buffer status report, will arrive, either 1) the length of the inactivity timer is very long, or 2) the grants for new data are transmitted at a subframe when the possible retransmission would occur if there had been a negative decoding result. Otherwise, the grant for new data is delayed until the next DRX cycle. If only long cycles are configured this would result in an unnecessarily long delay. However, having a very long inactivity timer is not desirable, because then there are not many opportunities for the UE to enter a sleep mode. The battery consumption of the UE would be high and there would not be any significant benefit to have the DRX at all. In addition, if there are retransmissions for the HARQ transmission having a BSR, the inactivity timer would be even much longer than 10 milliseconds (ms). For the downlink, the best performance of DRX is achieved with a short inactivity timer of a few subframes. If the UL requires a very long inactivity timer, this would decrease the performance of DRX with DL traffic. Also, constraining the possible grants for those subframes that are synchronized with 8 ms HARQ RTT time is not desirable. Having such a constraint would make scheduling more complicated and inefficient.